Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 2 sur 3 PremièrePremière 123 DernièreDernière
Affichage des résultats 31 à 60 sur 80

Discussion: PhysX

  1. #31
    Pour moi des effet physique intéressant aurraient pour effet de déformer les objets comme dans carmaggedon ou faire des trous partout comme dans red faction. Ca pourrait aussi modifier les textures. Actuellement les polygones/textures sont modifés par le CPU la plupart du temps, mais les shaders commencent à être assez flexibles pour le faire. Ajouter les calculs physiques dedans ne me parrait vraiment pas abérant, tout reste dans la RAM du GPU et le gain en temps de traitement est loin d'être négligable. Un début logique serait d'intégrer le dection de collision dans les GPU.

  2. #32
    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.
    Je vais peut être me répéter, mais il faut bien se rendre compte que faire des calculs physiques en temps réel un peu poussés ( c'est à dire à un autre niveau que se qui peut se faire actuellement dans les jeux qui sont franchement minimalistes sur ce point), ça demande un puissance de calcul qui devient vite phénoménale et tout aussi comparable à celle demandée par les calculs 3D.

    Pour faire une analogie grossière, les rendus 3D sont à la vue ce que les calculs physiques sont au toucher. Il y a une grosse focalisation générale sur tout ce qui est visuel actuellement (et ce n'est pas limité au monde du jeux vidéo, mais ce n'est pas le sujet), pourtant peut-on dire que la vue est moins importante que le toucher?
    OK, c'est un peu capilo-tracté, mais c'est un peu ça.

    D'autant plus que la physque ne se limite pas à la mécanique. La thermodynamique, l'éléctomagnétisme, ou même l'acoustique, c'est aussi des calculs physiques. Générer un son en temps réel en fonction des propriétés acoustiques d'un matériau, de sa vitesse de déplacement, de déformation, etc ca pourrait être génial et ça parait peu faisable uniquement avec une carte son un gpu et un cpu (qui n'a pas que cela à faire soi dit en passant).

    Franchement on est loin de modéliser correctement le réel ou de créer des environnements virtuels assez cohérents pour être crédibles, et la puissance de calcul nécessaire pour cela est potentiellement infinie. Ca m'étonne que l'on se pose la question de l'utilité d'un tel processeur...

    Je ne dis pas que ça sera tout de suite indispensable, ni que je vais acheter un physX demain, mais on n'est qu'au début. Ce n'est pas parce qu'aujourd'hui on n'affiche que des explosions vaguement améliorées qu'on ne sera pas capable de faire mieux demain.

    Maintenant que le hard est là, on peut espérer que le soft va suivre et exploiter tout ça, mais honnêtement je n'ai pas trop de doutes à se sujet.

  3. #33
    Citation Envoyé par Tridam
    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.
    Ce doit être le prix de la "réalité".
    Isn't it, Morpheus ?

    Tu sais si c'est une déclaration explicite dans le code pour chaque objet ou ce caractère "interférant" (pouvant avoir une incidence sur un autre objet) est déterminé dynamiquement (voire de manière spéculative) ?

    Edit @ Yoshi :
    Bien sur, c'est très couteux, mais il ne s'agit pas de tout modéliser dans les moindres détails.
    Comme la qualité du rendu 3D est fonction des perfs du GPU, la fidélité du modèle physique serait fonction des ressources CPU/PPU dispos.

    Pour la transformation du son selon l'environnement, je croix que l'EAX de Creative est fait pour ça (Reverb, etc.)

  4. #34
    Tous ces processeurs supplémentaires sont destinés à gagner quelques années sur les capacités du processeur principal. Dans tous les domaines il y a des choses à faire, la 3D l'a fait. Ca ne veut pas dire que c'est intéressant de le faire dans tous les domaines. Le problème de la physique "intéressante" c'est qu'elle n'intervient pas en bout de chaîne ce qui complique l'utilisation efficace d'un processeur dédié. Etant donné qu'elle affecte directement le gameplay il peut y avoir un déséquilibre en fonction du fait qu'on dispose ou pas dudit accélérateur. Faut-il développer et tester en profondeur 2 versions du gameplay pour chaque jeu ? Désactiver l'accélérateur physique dans les jeux multijoueurs ?

    Au niveau du rendu des personnages on en est à un point où on peut créer un visage très réaliste. Par contre pour les cheveux ça reste compliqué et rendre des cheveux aussi réalistes que le visage consommerait trop de ressources. Une HPU (hair processing unit) permettrait de faire un bond en avant à ce niveau. Est-ce une voie intéressante pour autant ?

    Je pense que démultiplier les accélérateurs dédiés n'est pas intéressant à terme. Bien entendu il y a des opportunités de business à ce niveau et il n'est pas impossible d'arriver à y créer un marché en rendant obligatoire l'utilisation d'un accélérateur supplémentaire, tout comme c'est le cas pour le GPU. Une fois la machine lancée, le software qui en tire partie démocratisé, et les brevets qui cadenacent le marché en place c'est bingo pour celui qui est arrivé à s'y introduire. Mais pas spécialement pour l'utilisateur puisque ça inclu un coût supplémentaire et que ça limite les possibilités (les accélérateurs dédiés sont prévus pour accélérer un fraction d'un domaine et finissent par rendre obligatoire de se limiter à ce domaine).

    Le PPU d'Ageia ce n'est pas un accélérateur physique dans sa globalité mais un accélérateur de quelques fonctions physiques.

    Actuellement je pense préfèrable de voir les GPU s'enrichir pour pouvoir traiter une plus grosse partie des calculs physiques et le reste rester sur des CPU qui pourraient, eux, incorporer plus de capacités de traitement spécifiques à certains algorithmes. Aux dernières nouvelles c'est la vision de l'API physique qui sera intégrée à DirectX.

  5. #35
    Il est clair que la carte graphique est la plus à même de gérer tout ce qui est "effets physiques". Ca fait un petit moment qu'on le voit et que des algorithmes existent (render to Vertex Buffer Object...). Mais à vrai dire ces effets physiques restent des effets purement visuels. La physique mise en avant dans les jeux c'est des objects qui tombent qui roulent qui s'entrechoquent...etc bref celle qui nécessite beaucoup plus d'interaction et de connaissance de l'environnement. Calculer des effets physiques dans une environnement dynamique ça demande de la puissance de calcul puissance non disponible sur une carte graphique!

    Je ne me suis pas bien penché sur l'implentation hardware d'Agia. D'après ce que j'ai cru comprendre c'est qu'il faut développer les algorithmes explicitement pour le hardware et explicitement pour le software. Si c'est le cas c'est une grosse erreur. Une seule API accélérée ou non suivant la présence ou non d'un PPU serait préférable. Un peu comme à l'époque d'OpenGL qui utilisait le T&L s'il était supporté par le GPU et ce de façon transparente pour le programmeur.

  6. #36
    Dans le cas de la carte d'Ageia, il faut aussi voir que le bus PCI utilisé actuellement bride très probablement les échanges entre le PPU, le CPU et la CG...

    Enfin, pour ce qui est des GPU, on peu faire pas mal de choses avec...d'ailleurs, comme en témoigne le site http://www.gpgpu.org/ certains ne s'en privent pas ;-)

  7. #37
    Citation Envoyé par Alice
    Je ne me suis pas bien penché sur l'implentation hardware d'Agia. D'après ce que j'ai cru comprendre c'est qu'il faut développer les algorithmes explicitement pour le hardware et explicitement pour le software. Si c'est le cas c'est une grosse erreur. Une seule API accélérée ou non suivant la présence ou non d'un PPU serait préférable. Un peu comme à l'époque d'OpenGL qui utilisait le T&L s'il était supporté par le GPU et ce de façon transparente pour le programmeur.
    J'ai lu le contraire sur le site :
    Citation Envoyé par http://support.ageia.com/ics/support/default.asp?deptID=1949
    ... you can use SW simulation with the PhysX SDK as preparation for use with PhysX HW--please be sure to note in the documentation which features currently have support in PhysX HW scenes (post 2.5, this will no longer be a concern, as every feature of the SDK will be available in both HW and SW scenes).
    Reste à savoir si le "simulateur" vaut le coup, si c'est un moteur valable ça peut être intéressant.

    Citation Envoyé par Gary Winston
    Dans le cas de la carte d'Ageia, il faut aussi voir que le bus PCI utilisé actuellement bride très probablement les échanges entre le PPU, le CPU et la CG...
    Il n'y a que des objets tranférés plus les algos c'est vraiment rien pour le bus PCI a mon avis.

  8. #38
    Lors de l'E3 : entretien avec Tim Sweeney

    Jacob - How will UT2007 use Ageia enhanced physics effects? Increased object count? Fluid effects?

    Sweeney- Anywhere from explosions to have physically interacting particles... we are also looking at fluid effects to see where we can use those, gee, blood spurts sound like they might be a good candidate! A lot of other special effects like that, where they don’t affect the core game play, so that players with the physics hardware and players without the physics hardware can all play together without any restrictions.

    Jacob- There was a lot of controversy with the recently released Ghost Recon, where some players got lower performance when enabling Ageia effects because the video card has to render more objects. Is that something that should be expected or should frame rate be the same?

    Sweeney- For the record, acceleration hardware is supposed to accelerate your frame rate, not decrease it! [laughs] That seems like it’s just a messy tradeoff that they made there. You certainly want your physics hardware to improve your frame rate. That means that the physics hardware might in some cases be able to update more objects so you can actually render another frame, so you need to have some sort of rendering LOD scheme for that to manage the object counts, and obviously you don't want to take this ultra fast physics card and plug it into a machine with a crummy video card. You really want to have a great video card to match up with your physics hardware and also a decent CPU to have your system in balance to really be able to take advantage of the full thing.
    Jacob- Havok recently announced the ability to accelerate physics on the GPU. Is that necessarily a bad idea?

    Sweeney- That’s a good approach, they have some good technology there. Havok has a physics system that runs largely on the GPU to accelerate the computations there. It seems to be a lower precision physics than you have for the rest of the game which is problematic. You really want all the physics in the world to be drawing with a constant level of precision, so you don't have to make weird trade-offs there. I guess there is also the trade-off with that, if your GPU is doing both physics and graphics, then you are not getting the full utilization out of the system.

    Jacob- One more question, kinda in the same fashion, Conroe or AM2?

    Sweeney- Haha, well that’s hard to say, I don't know much about AM2, but Conroe is a really fantastic chip. The funny thing is very few people in the industry have been willing to come out and say that the Pentium 4 architecture sucks. It sucked all along. Even at the height of it's sucking, when it was running at 3.6GHz and not performing as well as a 2GHz AMD64... People were reluctant to say it sucked... so IT SUCKS! But Conroe really makes up for that and I am really happy to see that, that Intel is back on this track of extremely high computing performance at reasonable clock rates. Not having to scale up to these extremely hot running systems that require a lot of cooling. I think they are on a good track there and if they scale the Conroe architecture up to four and eight cores in the future, then that will put the industry on a really good track for improving performance dramatically at a faster rate than we have seen in the past.
    Tim Sweeney donne son avis sur le Megatexturing, l'unification des shaders...

    http://www.nvnews.net/vbulletin/showthread.php?t=70056

  9. #39
    Citation Envoyé par Sh4dow
    Lors de l'E3 : entretien avec Tim Sweeney

    Jacob- One more question, kinda in the same fashion, Conroe or AM2?

    Sweeney- Haha, well that’s hard to say, I don't know much about AM2, but Conroe is a really fantastic chip. The funny thing is very few people in the industry have been willing to come out and say that the Pentium 4 architecture sucks. It sucked all along. Even at the height of it's sucking, when it was running at 3.6GHz and not performing as well as a 2GHz AMD64... People were reluctant to say it sucked... so IT SUCKS! But Conroe really makes up for that and I am really happy to see that, that Intel is back on this track of extremely high computing performance at reasonable clock rates. Not having to scale up to these extremely hot running systems that require a lot of cooling. I think they are on a good track there and if they scale the Conroe architecture up to four and eight cores in the future, then that will put the industry on a really good track for improving performance dramatically at a faster rate than we have seen in the past.

    http://www.nvnews.net/vbulletin/showthread.php?t=70056
    Le rapport avec le sujet ?

  10. #40
    Dans le cas de la carte d'Ageia, il faut aussi voir que le bus PCI utilisé actuellement bride très probablement les échanges entre le PPU, le CPU et la CG...
    si le port PCI bride tant que ce le PPU, serait-il possible de le mettre sur PCI-E (comme ca on aura enfin une utilité pour ce deuxième port)

  11. #41
    Citation Envoyé par pyrignis
    si le port PCI bride tant que ce le PPU, serait-il possible de le mettre sur PCI-E (comme ca on aura enfin une utilité pour ce deuxième port)
    Oui. La carte d'aegia était d'ailleurs mixte pci pci-e.
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  12. #42
    Citation Envoyé par jihef
    Oui. La carte d'aegia était d'ailleurs mixte pci pci-e.
    D'après ce que j'ai compris c'était une carte basée sur un ancien design de la puce qui supportait une connectique très variée (pas uniquement PCI et PCIE). Le design final ne supporterait que le PCI et ils devraient donc refaire une nouvelle puce.

    D'après les partenaires, il n'y aura pas de version PCIE avant 2007.

  13. #43
    Un commentaire méchant mais peut-être juste que j'ai entendu dans un podcast, grossièrement traduit de l'anglais "Alors nous remercions Ageia d'avoir donné à ATI et nVidia l'idée et la nécessité d'intégrer la gestion de la physique dans leurs puces, et au revoir Ageia, bonne faillite."
    "La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24

  14. #44
    Citation Envoyé par Minuteman
    Un commentaire méchant mais peut-être juste que j'ai entendu dans un podcast, grossièrement traduit de l'anglais "Alors nous remercions Ageia d'avoir donné à ATI et nVidia l'idée et la nécessité d'intégrer la gestion de la physique dans leurs puces, et au revoir Ageia, bonne faillite."
    Comme 3Dfx : pionnier, mais loser commercial à la fin.

  15. #45
    Je me demande vraiment pourquoi cette carte n'est pas PCI-E. Au-dela du fait que ce soit utile ou non, le public visé par cette carte a forcément un pc récent avec support PCI-E. Il y a aussi l'image que ca véhicule, le PCI est vieux et dépassé alors que le PCI-E a une meilleure image niveau technologie sans compter les avantages réels. A moins que ce ne soit que pour faire changer de carte pour la deuxième génération parce qu'il n'y aura plus de PCI ?
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  16. #46
    Ce ne sont pas forcément des loser s'ils sont blindé de brevets...

  17. #47
    Si le fait que Cell Factor puisse tourner de la même manière avec ou sans carte, Si !
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  18. #48
    D'après ce que j'ai compris c'était une carte basée sur un ancien design de la puce qui supportait une connectique très variée (pas uniquement PCI et PCIE). Le design final ne supporterait que le PCI et ils devraient donc refaire une nouvelle puce.

    D'après les partenaires, il n'y aura pas de version PCIE avant 2007.
    peut-etre utiliseront-ils les ports HTX d'AMD, qui permettent de communiquer dirrectement avec le processeur, et donc de reduire la latence...

  19. #49
    Citation Envoyé par pyrignis
    peut-etre utiliseront-ils les ports HTX d'AMD, qui permettent de communiquer dirrectement avec le processeur, et donc de reduire la latence...
    pour moi, aucune chance...
    Mes propos n'engagent personne, même pas moi.

  20. #50
    Citation Envoyé par pyrignis
    peut-etre utiliseront-ils les ports HTX d'AMD, qui permettent de communiquer dirrectement avec le processeur, et donc de reduire la latence...
    Oui et puis avec le parc de machines bi socket ils ont un marché énorme :loop:

  21. #51
    Citation Envoyé par Marc
    Oui et puis avec le parc de machines bi socket ils ont un marché énorme :loop:
    c'est pour ce point précis que j'ai mis "aucune chance"
    Mes propos n'engagent personne, même pas moi.

  22. #52

  23. #53
    pour moi, utiliser une carte graphique "reconfigurée" est pas pas plus une aberration qu'une carte dédiée comme la PhysX.

    c'est juste un moyen de vendre quelque chose, en pensant que ça a marché sur le marché de la 3D il y a quelques années.
    Mais le contexte est différent, et les possibilités aussi.

    ce que font les cartes "physiques" ou ce que comptent faire ATI et Nvidia, les CPU actuelles peuvent le faire, plus lentement, certes (quoique) mais c'est faisable avec un CPU haut de gamme.

    ce que faisaient les premières cartes 3D grand public (Voodoo de 3DFX) et ce que font les GPU actuels, je vois mal les CPU le faire actuellement (je sais bien que les évolutions des cartes graphiques sont venues en parties des orientations 3D polygonées, mais quand même).


    Le jour ou j'ai le même choc avec un truc "physique" que la première fois ou j'ai vu jeu accéléré 3dfx (Pod pour ne pas le citer) face à la version classique, je révise mon jugement. Mais des fumées qui tombe pas, ça m'impressione pas.

  24. #54
    L'aberration est pour moi évidente.

    "Ne vous servez pas d'une carte dédiée pour la physique. Ca sert à rien vu que l'on peut faire la même chose voire plus avec votre carte graphique... Ah oui par contre n'oubliez pas d'acheter une de nos cartes graphiques en plus car il faut qd même afficher des images qui demandent beaucoup en ressource GPU".

    Bref n'achetez pas une carte spécialisée mais une carte reconfigurée. C'est du marketing rien de plus qui consiste à pousser le consommateur à acheter un produit et pas un autre. Une carte graphique sert à faire... du graphique. Pourquoi privilégier pour les calculs physiques, une solution dédiée au graphique par rapport à une solution spécialement étudiée pour la physique? Que le PPU soit performant ou pas dans l'état actuel des choses, n'a même pas d'importance. L'idée en elle même suffit à souligner l'incohérence dans le raisonnement.

    Faire le paralléle GPU/PPU est un peu risqué. On va redire encore des banalités mais les tâches à affectuer par un GPU sont très souvent hautement parrallélisables a contrario des calculs physiques. Je ne remets cependant pas en cause l'intérêt d'un solution dédiée. Cependant je pense qu'on a évincé trop rapidement la puissance de calcul offerte par le tout parallélisme vers lequel s'engoufre les CPU.

  25. #55
    Ca me donne l'impression qu'on pourrait assister à un retours des coprocesseurs.
    Un GPU c'est actuellement un processeur dédié aux calculs hautement vectoriels. Ca peut également traiter des calculs non "graphiques", le problème étant le temps de chargement des données. Si les calculs physiques sont aussi fortement vectoriels (je ne sais pas vraiment), cela peut se faire avec le GPU.
    Nos CPU sont en train de migrer vers une augmentation du nombre de coeurs, et privilégient actuellement l'efficacité des calculs non vectoriels (sinon il fallait garder Netburst).
    Avec un bus d'interconnection copro/cpu efficace (style HT), il ne me semblerait pas complêtement absurde de voir nos machines évoluer vers un couple CPU multicore / processeur vectoriel (pourquoi pas multicore), tous deux sur la carte mère.
    Je trouve que les possibilités seraient assez interessantes. Bien sûr cela nécessiterait une évolution de pas mal de programmes, mais hors du monde PC il n'est pas si rare d'utiliser des unités de traitement aux caractéristiques différentes simultanément.

  26. #56
    Citation Envoyé par Gabriel
    Un GPU c'est actuellement un processeur dédié aux calculs hautement vectoriels.
    Un GPU est massivement threade, ce qui est en general considere comme exactement l'inverse de vectoriel .
    fefe - Dillon Y'Bon

  27. #57
    Sans blague personne n'a vu le type qui a pu faire tourner Cell Factor sans PPU exactement comme si y'en avait un. PPU ou pas c'était pareil. C'est vraiment n'importe quoi !
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  28. #58
    J'avais l'impression qu'un GPU faisait beaucoup de calculs sur des vecteurs relativement grands.
    Sur un CPU x86, le max qu'on puisse faire c'est un vecteur de 16 éléments, et seulement si on reste sur 8 bits. Les vecteurs traités par les GPU ne sont-ils pas plus grands que ça?
    Je sens qu'il faudrait que je refasse un peu de lecture...

  29. #59
    la largeur d'un vecteur pour un GPU fait 128 bits, x,y,z,w en simple precision, c'est a dire comme altivec, SSE et consorts (4 elements). En revanche ils utilisent enormement (16+) unites de calcul capable de traiter ces donnees sur 128 bits. Afin de maximiser l'utilisation de ces unites de calcul les GPU schedulent un nombre important de thread (>>16) pour recouvrir les latences des unites de calcul.

    Donc dans un GPU tu as souvent 50+ threads avec des vecteurs de 4 elements, ce qui correspond a une machine massivement threadee et pas a ce que l'on appelle traditionellement une machine vectorielle.
    fefe - Dillon Y'Bon

  30. #60
    Ok, donc un GPU peut faire des calculs sur 16 vecteurs simultanément, mais n'est pas limité à faire les mêmes calculs simultanément sur ces 16 vecteurs.
    (merci)
    D'après ce que j'ai vu, un PPU c'est un peu similaire, avec un gros problème en plus: les calculs ne sont pas indépendants les uns des autres.
    J'ai quand même l'impression qu'un GPU et un PPU se ressemblent pas mal.
    Moi je verrais bien une seule puce faire les 2.
    Placer ce genre de puces sur un socket de la carte mère avec une liaison HT serait assez pratique, dans la mesure où cela pourrait être remplacable par d'autres processeurs/copro/fpga suivant les développement.
    Resterait à placer les I/O physiques sur le PCI express.
    Point négatif par contre: une augmentation de la latence mémoire principale.

    En tout cas, ça me paraitrait très souple.

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
  •