Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 1 sur 3 123 DernièreDernière
Affichage des résultats 1 à 30 sur 80

Discussion: PhysX

  1. #1
    Je viens de voir que Asus avait envoye a qq sites de review des cartes utilisant le PhysX d'AGEIA. Les reviews sont un peu sans pitie, vu qu'il n'y a quasiment pas de soft pret et que sur les applications non synthetiques la carte agit comme un frein .
    Dans le doute je pense qu'ils ont un bug avec leurs drivers/microcode pour certains effets utilises sur les explosions (le cas qui decelere) et qu'ils ne l'avaient pas repere/corrige sur les cartes qui ont ete donnes pour la preview (a moins que leurs PR soient des debiles profonds et qu'ils donnent a review qq chose qu'il savent faire une pub catastrophique). Qui plus est j'ai du mal a voir Sweeney investir des dev pour le supporter dans le moteur d 'U3 sans qq arguments.

    Qq1 a-t'il eu l'occasion de jeter un oeil au SDK ? Ca serait interressant d'ecrire 2-3 microbenchs simples histoire de voir ce que la carte a dans le ventre et de la comparer a un CPU actuel, car pour l'instant il n y a pas moyen de choisir entre rendu soft et hard des effets (ce dont tt le monde se plaint). Je suis sur qu'il y a des primitives assez simples pour faire ce genre de choses et ca permettrait de publier autre chose que des perf peak.
    fefe - Dillon Y'Bon

  2. #2
    Il y'a une petite demo de ageia qui tourne soit en soft soit en hard, damien l'a utilisée dans son test.

  3. #3
    Oui mais malheureusement il n'est pas difficile de se debrouiller pour que la version soft soit "lente" et artificiellement favoriser la version acceleree quand c'est toi (AGEIA) qui ecrit le code. Il suffit de ne pas optimiser a fond la version soft...

    Et pour une appli ecrite par eux, c'est loin d'etre folichon.
    fefe - Dillon Y'Bon

  4. #4
    Citation Envoyé par fefe
    Oui mais malheureusement il n'est pas difficile de se debrouiller pour que la version soft soit "lente" et artificiellement favoriser la version acceleree quand c'est toi (AGEIA) qui ecrit le code. Il suffit de ne pas optimiser a fond la version soft...
    Y'en a qui font ça ?? :D

    Le test d'Anantech c'est du grand n'importe quoi, le FPS est divisé par quatre en hardware dans certains tests d'explosions (sur Ghost Recon). Y'a forcément un problème, je doute que la carte serait sortie dans ces conditions.

  5. #5
    C'est normal que ça soit plus lent avec PhysX que sans. Les configs testée avec GRAW essentiellement ont un CPU qui n'est pas saturé par les calculs physiques (un FX ou EE :/), le goulot c'est la CG. La carte PhysX va soulager le CPU qui n'était pas saturé et rajouter plein de particules et d'autres objets qui vont "saturer" encore plus la CG.

  6. #6
    Ce qui vient confirmer la cible de la carte en même temps.
    Ceux qui ont déja de la grosse CG voir du SLi et +

  7. #7
    Marc (ou ceux qui on une) tu pourrais tester cette demo => http://pp.kpnet.fi/andreasm/physx/ si tu a encore la carte .

    Cette demo fonctionne aussi en software en installant les derniers drivers Ageia, mais elle rame méchament sans carte PhysX (1à2 Fps environ chez moi avec un P4-Mobile@3.3Ghz avec la physique d'activer ).

    D'apres l'auteur elle comporte environ 3000 cubes empilés pour former une muraille qui se détruit en lancant un projectile avec la touche "Espace". Voici aussi des photos avec l'occupation CPU de cette demo avec et sans PPU => http://www.xtremesystems.org/forums/...&postcount=234.


    [EDIT] Je vient de trouver aussi une bidouille pour lancer la demo du jeu Cellfactor sans PPU ici => http://forums.guru3d.com/showthread.php?t=182533 . Ca serait pas mal de faire une comparaison sur ce jeu avec et sans PPU pour voir l'impact sur les performances.

  8. #8
    Citation Envoyé par fennec
    C'est normal que ça soit plus lent avec PhysX que sans. Les configs testée avec GRAW essentiellement ont un CPU qui n'est pas saturé par les calculs physiques (un FX ou EE :/), le goulot c'est la CG. La carte PhysX va soulager le CPU qui n'était pas saturé et rajouter plein de particules et d'autres objets qui vont "saturer" encore plus la CG.
    Euh, tout dépend de la résolution de test, je ne pense pas que certains se soient amuser à tester dans des cas non CPU Limited.

  9. #9
    Citation Envoyé par Franck@x86
    Y'en a qui font ça ?? :D

    Le test d'Anantech c'est du grand n'importe quoi, le FPS est divisé par quatre en hardware dans certains tests d'explosions (sur Ghost Recon). Y'a forcément un problème, je doute que la carte serait sortie dans ces conditions.
    Damien à obtenu les mêmes résulstats sous Ghost Recon et sous BoS donc bon, c'est un peu facile de mettre ca sur le dos d'AnandTech

  10. #10
    Citation Envoyé par Primus
    Marc (ou ceux qui on une) tu pourrais tester cette demo => http://pp.kpnet.fi/andreasm/physx/ si tu a encore la carte .

    Cette demo fonctionne aussi en software en installant les derniers drivers Ageia, mais elle rame méchament sans carte PhysX (1à2 Fps environ chez moi avec un P4-Mobile@3.3Ghz avec la physique d'activer ).

    D'apres l'auteur elle comporte environ 3000 cubes empilés pour former une muraille qui se détruit en lancant un projectile avec la touche "Espace". Voici aussi des photos avec l'occupation CPU de cette demo avec et sans PPU => http://www.xtremesystems.org/forums/...&postcount=234.


    [EDIT] Je vient de trouver aussi une bidouille pour lancer la demo du jeu Cellfactor sans PPU ici => http://forums.guru3d.com/showthread.php?t=182533 . Ca serait pas mal de faire une comparaison sur ce jeu avec et sans PPU pour voir l'impact sur les performances.
    Merci je transmet à Tridam il a encore la carte normalement, ca peux être interressant.

  11. #11

  12. #12
    Citation Envoyé par Marc
    Damien à obtenu les mêmes résulstats sous Ghost Recon et sous BoS donc bon, c'est un peu facile de mettre ca sur le dos d'AnandTech
    J'ai pas dit ça.
    Anandtech ou hardware.fr, les résultats n'en restent pas moins du grand n'importe quoi.

    Le jeu a été testé avant de sortir ? C'est à se demander.

  13. #13
    C'est bien ce que les gens ont lorsqu'ils mettent une carte PhysX à l'heure actuelle dans le PC, après ...

    Et les résultats sont les mêmes sous BoS (qui est un jeu incroyablement moche à ce propos :D )

  14. #14
    Citation Envoyé par Marc
    Euh, tout dépend de la résolution de test, je ne pense pas que certains se soient amuser à tester dans des cas non CPU Limited.
    Dans la preview de HFR le cpu est un FX55.

  15. #15
    Dans les tests que j'ai faits on est bel et bien CPU limited, j'avais bien entendu vérifié ce point.

    Ageia a sorti un nouveau driver censé améliorer les performances sous GRAW mais je n'ai remarqué aucun changement sur ma scène de test.

    Je vois 2 problèmes potentiels :
    - la latence des calculs physiques réalisés par le PPU ne sont pas masqués et donc le CPU perds pas mal de temps à attendre que les résultats arrivent; vu que la différence concerne uniquement l'ajout de particules on peut supposer que le tout aurait pu être plus efficace si rendu uniquement à partir de CPU et GPU
    - il faut convertir les données dans un format approprié avant de les envoyer au PPU ce qui peut augmenter sensiblement la charge du CPU; là aussi on peut imaginer que cette charge est supérieure au traitment en direct par le CPU des calculs supplémentaires

    Je pense que le gros problème de GRAW et BOS c'est de faire appel à l'artillerie lourde pour n'ajouter que quelques particules qui ne servent que d'effet visuel. C'est ridicule et totalement inefficace, d'autant plus que ça a été rajouté par dessus le reste et pas à la base.

  16. #16
    Une solution type Havok qui ferait faire les calculs physiques par le GPU serait-elle une piste?
    Un pb d'archi? un PPU plus rapide? sur un bus plus rapide?

  17. #17
    Citation Envoyé par Tridam
    Dans les tests que j'ai faits on est bel et bien CPU limited, j'avais bien entendu vérifié ce point.

    Ageia a sorti un nouveau driver censé améliorer les performances sous GRAW mais je n'ai remarqué aucun changement sur ma scène de test.

    Je vois 2 problèmes potentiels :
    - la latence des calculs physiques réalisés par le PPU ne sont pas masqués et donc le CPU perds pas mal de temps à attendre que les résultats arrivent; vu que la différence concerne uniquement l'ajout de particules on peut supposer que le tout aurait pu être plus efficace si rendu uniquement à partir de CPU et GPU
    - il faut convertir les données dans un format approprié avant de les envoyer au PPU ce qui peut augmenter sensiblement la charge du CPU; là aussi on peut imaginer que cette charge est supérieure au traitment en direct par le CPU des calculs supplémentaires

    Je pense que le gros problème de GRAW et BOS c'est de faire appel à l'artillerie lourde pour n'ajouter que quelques particules qui ne servent que d'effet visuel. C'est ridicule et totalement inefficace, d'autant plus que ça a été rajouté par dessus le reste et pas à la base.
    Je suis bien d'accord avec toi, pour l'instant même leur jolie demo (cellfactor ?) ne m'exite pas plus que ça, je ne vois pas d'ailleurs quels sont les calculs physique requis pour des particules, la trajectoire ? on peut la pré-calculer facilement.

    L'idéal serait un univers totalement destructible en fonctione des critères de materiaux, qu'on puisse enfin exploser une porte en bois avec un lance rockettes :/

    Le problème c'est qu'il faudrait totalement dédier le développement du jeu a la carte en question, et aucun dev ne saurait se contenter d'un marché aussi hypothétique. Paradoxalement il faudrait que ATI et Nvidia développent eux aussi leurs accélérateurs basés sur les shaders pour que ce genre de jeux se démocratise !

  18. #18
    Ce qui m'étonne un peu quand je lis des propos sur le physX, c'est que je vois partout des gens sceptiques (pas forcément ici, hein :D ), qui disent que ca ne va servir à rien. Pourtant quand on regarde bien, je trouve que c'est pas si éloigné de ce qui s'est passé avec les cartes graphiques.

    A l'époque on avait de la 3D très simple calculée par le cpu, qui était pourtant vite à genoux. Du coup on a développé des processeurs dédiés, ce qui a permis d'obtenirs de rendu 3D de meilleure qualité, et ca progresse encore (avant le raytracing en temps réel, y'a encore de boulot )

    Aujourd'hui c'est un peu pareil; Les calculs physiques sont fait par le cpu, et sont relativement basiques. Si on veut pouvoir intégrer des modélisations plus complexe (je ne dirais plus réalistes, mais plutôt plus cohérentes, je dirais après pourquoi), passer par un micro processeur dédié capable de fournir la puissance nécessaire est une solution qui semble viable.

    Pour ceux qui semblent se poser des questions sur l'utilité de toute cette puissance disponible, je dirais que les calculs à faire peuvent largement concurrencer les calcul de rendu 3D au niveau de la puissance nécessaire.

    Par exemple pour augmenter sensiblement la cohérence d'une scène, on peut faire tous les calculs physiques par éléments finis et en temps réel. Et là, je peux vous dire que la puissance fournie par un processeur dédié ne sera pas du luxe, la puissance nécessaire à ces calculs est potentiellement infinie, au même titre que le nombre de polygones affichés par une carte graphique.

    En ce qui concerne l'implantation du PPU dans le PC, d'une part je pense qu'elle est plus complexe que lorsque les cartes graphiques sont arrivées parce qu'il y a beaucoup plus de choses dans nos PC maintenant qu'à l'époque avec lesquelles il faut s'accorder, d'autre part, on peut penser que cela sera amené à évoluer à la manière là aussi des cartes graphiques qui ont débuté sur port PCI, pour avoir de nos jours un bus dédié et pensé pour.

    Pour conclure, je pense que c'est une technologie pas facile à mettre en place, moins qu'on pourrais le croire en tout cas, ceci dit il me semble que les possibilités offertes sont plus qu'intéressantes (et pas seulement dans les jeux, les calculs par éléments finis, ca sert dans plein d'autres domaines).

    PS : au sujet de la cohérence, je dis ça plutôt que réalisme, parce qu'après tout, on est pas obligé de coller au réel, rien n'empêche de créer ses propres équations physiques, décrivant un monde différent du notre (sans pour autant être moins complexe)

    PPS : au sujet de mon exemple sur les éléments finis, je dois dire que je ne sais pas si le physX est aujourd'hui capable de réaliser de tels calculs, mais cela me semble une voie d'évolution assez logique à plus ou moins long terme.

  19. #19
    La grosse différence, c'est qu'avec les 3DFX (premier en grand public, non ?) on se prenait une grosse claque graphique. Le jeu optimisé était à des années lumières de la version normale.
    Et le Glide permettait une mise à jour 3DFX assez rapide (j'avais lu à l'époque 2 à 3 jours de travail maximum pour passer un jeu en Glide, en gros changer le nom des fonctions simples). Bon, les jeux patchés gagnaient essentiellement le filtrage et plus de rapidités, mais ça se voyait bien.

    Avec les cartes PhysX, j'ai vu que 2 trus dans les tests : des particules et des beaux effets de fumées. Sans que le jeu soit spécialement plus rapide. Et ces 2 trucs là, on sait le faire sans cartes en fait.

    Quand on aura un (ou des) jeux pensés au départ pour utiliser le PhysX, ce sera sureùent plus impressionant et intéressant, mais pour le moment je trouve pas ça fort impressionant.

    enfin, il y a un gros problème, je trouve : c'est super cher quand même.

  20. #20
    Moi j'ai surtout l'impression que le marché des jeux vidéos est beaucoup plus rigide actuellement qu'à l'époque de 3dfx, Rendition et PowerVR. Le fait est qu'il n'existe plus que quelques grands studios de développement (EA au bol) et que ces gens n'ont certainement aucun intérêt à passer du temps à programmer leurs jeux pour différentes API. Avant l'intégration de la physique dans DirectX, je ne vois pas vraiment de salut pour ces solutions...
    "La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24

  21. #21
    Citation Envoyé par Minuteman
    Avant l'intégration de la physique dans DirectX, je ne vois pas vraiment de salut pour ces solutions...
    +1

    ou openPL (avec opengl et openal)
    Mes propos n'engagent personne, même pas moi.

  22. #22
    Citation Envoyé par yoshi133
    A l'époque on avait de la 3D très simple calculée par le cpu, qui était pourtant vite à genoux. Du coup on a développé des processeurs dédiés, ce qui a permis d'obtenirs de rendu 3D de meilleure qualité, et ca progresse encore (avant le raytracing en temps réel, y'a encore de boulot )

    Aujourd'hui c'est un peu pareil; Les calculs physiques sont fait par le cpu, et sont relativement basiques. Si on veut pouvoir intégrer des modélisations plus complexe (je ne dirais plus réalistes, mais plutôt plus cohérentes, je dirais après pourquoi), passer par un micro processeur dédié capable de fournir la puissance nécessaire est une solution qui semble viable.

    Pour ceux qui semblent se poser des questions sur l'utilité de toute cette puissance disponible, je dirais que les calculs à faire peuvent largement concurrencer les calcul de rendu 3D au niveau de la puissance nécessaire.
    Oui, mais il y a 2 points qui diffèrent par rapport au rendu 3D :
    - la disponibilité de puissance au niveau du CPU (multicore) qui n'existait précédemment
    - la nature des calculs

    Pour le rendu 3D, du fait de l'indépendance des traitements, un CPU OOO n'était pas forcement le plus adapté. Un processeur sans cette logique et avec beaucoup plus d'unités de traitement était alors plus intéressant.
    Pour la gestion de la physique, du fait de la nature dépendante des traitements (fortes interactions entre les corps), cet intêret n'existe plus. A la rigueur, un CPU avec un nombre FLOPS important (Cell again ?) pourrait être plus intéressant.

    D'ailleurs, il est OOO ou IO le PhysX ?

  23. #23
    Citation Envoyé par ylad
    Une solution type Havok qui ferait faire les calculs physiques par le GPU serait-elle une piste?
    Non surtout pas!!! :nuts: Je me demande qui a eu cette idée de donner à la carte graphique du travail en plus. C'est totalement abérant de surcharger la carte graphique qui en a déjà plein les dents. Ce n'est pas demain la veille que le GPU va se tourner les pouces dans un jeu. Par contre dans le cadre du GPGPU là il y a un certain (grand?) intérêt... Le seul problème c'est qu'ATI et NVidia sous entendent l'utilisation de la physique sur GPU dans le cadre d'applications ludiques !! :heink: Leur démarche me parait être... hmmm... du marketing !

  24. #24
    Citation Envoyé par Alice
    Non surtout pas!!! :nuts: Je me demande qui a eu cette idée de donner à la carte graphique du travail en plus. C'est totalement abérant de surcharger la carte graphique qui en a déjà plein les dents. Ce n'est pas demain la veille que le GPU va se tourner les pouces dans un jeu. Par contre dans le cadre du GPGPU là il y a un certain (grand?) intérêt... Le seul problème c'est qu'ATI et NVidia sous entendent l'utilisation de la physique sur GPU dans le cadre d'applications ludiques !! :heink: Leur démarche me parait être... hmmm... du marketing !
    Je suis entièrement d'accord sur le fait que le GPU va souffrir. Cependant, c'est le problème de latence auquel je pensais. L'archi actuelle, on a le PPU qui fait les calculs de particules, qui transitent alors par le CPU puis ils sont envoyés au GPU pour affichage.

    En fait, avoir un PPU en carte d'extension, oui, mais pluggué sur la CG directement.

  25. #25
    Faire traiter la physique à la carte graphique reste aberrant tant que le processeur de la carte graphique reste dédié au rendu 3D.
    Maintenant, si les constructeurs de CG décident d'ajouter dans leur chip une architecture supplémentaire dédiée à la physique, alors en théorie pourquoi pas.
    En pratique, voila le nombre de transistors et le système de refroidissement qu'il va falloir... (quand on voit déja ce qu'il faut rien que pour le rendu 3D).
    Et puis la gestion de la physique est quand même plus proche dans la nature des traitements du calcul de la scène fait par le CPU (positionnement des différents éléments, ...) que de son rendu graphique.
    Alors en plus si le CPU a des cores qui se tournent les pouces, je vois vraiment pas l'intérêt.
    ATI et nVidia devraient plutôt se concentrer sur le rendu 3D, y a encore pas mal de boulot de ce coté... et puis les ordinateurs ont déja un processeur hétéroclite, peut être pas besoin d'un second...

  26. #26
    Avec une archi de type DX10, le traitement de la physique apparaît de plus en plus naturel pour les GPUs, tout du moins pour une partie de la physique.

    Havok FX, ce n'est pas un saut technologique comme les communiqués de Nvidia/Havok tentent de le faire croire. Une partie de ces calculs peut déjà être traitée par le GPU dès maintenant et ça l'est d'ailleurs déjà dans certains cas pratiques. Ce qu'Havok propose c'est un ensemble de bouts de code tout faits qui sont optimisés pour s'interfacer optimalement avec le reste de son moteur physique. Ce n'est pas une révolution.

    La partie complexe de la physique qui influe sur le gameplay ce n'est pas pour le GPU. Ca reste sur le CPU ou le PPU, mais personnellement je ne trouve pas intéressant au vu de l'évolution proche et à plus long terme des CPU et des GPU de rendre nécessaire l'utilisation d'un processeur additionnel. A la limite il suffit de se dire que les 100 millions de transistors du PPU seront bientôt "facilement" engoufrables dans un GPU ou un CPU. Ageia a déclaré prévoir de rester 2 ans et demi avec cette première puce.

  27. #27
    Citation Envoyé par Tridam
    Avec une archi de type DX10, le traitement de la physique apparaît de plus en plus naturel pour les GPUs, tout du moins pour une partie de la physique.
    Citation Envoyé par Tridam
    La partie complexe de la physique qui influe sur le gameplay ce n'est pas pour le GPU.
    On peut séparer le traitement de la physique ?
    Que veux-tu dire par "complexe" ? Que reste t'il si on enlève "toute la physique qui influe sur le gameplay" ?
    Je sais pas, je vois ça comme un tout, des forces et des propriétés physiques (masse, centre de gravité, consistance, resistance, cohésion, etc.)

  28. #28
    L'antenne qui bouge sur le toit d'une voiture de rallye c'est de la physique, le piano qui tombe sur le joueur qui passe sous une fenêtre c'est aussi de la physique. Dans le premier cas ça rend juste ce qu'on voit à l'écran plus réaliste, dans le second ça tue le joueur.

    Effect physics = amélioration visuelle grâce à la physique
    Game physics = amélioration du game play grâce à la physique

    Dans le premier cas les calculs peuvent se faire en bout de chaîne, ils ne doivent pas être analysés par le moteur du jeu pour entrainer un résultat sur le joueur, un autre personnage etc. Dans le second cas ils doivent être communiqués au CPU.

    Dans BOS et GRAW on est dans le premier cas pour ce qui est traité par le PPU, c'est simplement de la "physique d'effet".

  29. #29
    Cette séparation entre interactions ayant ou non une incidence sur le gameplay me semble difficile à mettre en pratique : comment le savoir à l'avance ?
    En reprenant l'exemple du piano, comment savoir au moment où le piano commence à chuter que le joueur va se trouver en dessous pile au mauvais moment ? La physique du piano devra toujours être traitée par le CPU ?

    Pour avoir quelque chose de réaliste, dans tous les cas la physique devrait influer sur le gameplay puisqu'il est soumis à ses lois. C'est même la physique elle-même qui détermine si elle va avoir une influence sur le gameplay.
    Un exemple : soit un objet de masse m, de vitesse v et de coefficient de pénétration b (comme b...) qui entre en contact avec le perso. Retrait de x HP au perso avec x=k*m*v*b
    - la tête : k=1.27
    - le torse : k=0.84
    ...
    m est constant, mais v, b et l'endroit du contact sont régits par les forces qui s'appliquent sur l'objet en question (et sur le perso).
    Si x < 1, alors pas d'incidence sur gameplay
    Si 1 <= x < 10, retrait HP au perso mais sans incidence sur son comportement
    Si 10 <= x < 50, retrait HP au perso et incidence sur son comportement (perso bousculé, mis à terre, ...)

    Je sais pas si j'ai été clair...
    :gne:

  30. #30
    Citation Envoyé par Yasko
    Cette séparation entre interactions ayant ou non une incidence sur le gameplay me semble difficile à mettre en pratique : comment le savoir à l'avance ?
    En reprenant l'exemple du piano, comment savoir au moment où le piano commence à chuter que le joueur va se trouver en dessous pile au mauvais moment ? La physique du piano devra toujours être traitée par le CPU ?
    Oui.

    On est encore à des années lumières d'une scène entièrement régie par les lois physiques. On en est encore et on en sera encore pour un moment je pense au cas par cas.

    Il n'y a pas que la technique qui pose problème mais tout l'aspect gameplay qui devient beaucoup plus difficile à gérer. Qu'est-ce qui se passe si à cause de la physique des objets lourds sont déplacés et bloquent un passage obligatoire ? Comment obliger le joueur à faire 3x le tour de la map pour récupérer une clé alors qu'il a un passe partout qui s'appelle bazooka ? Comment on récupère un pass qui se trouvait dans un bâtiment qu'on vient de démolir entièrement ? etc.

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •