Reprise du message précédent :

 
Pardon ?
Verrouiller le support software du PhysX à un seul core, c'est pas locker les jeux PhysX pour que ca tourne mal sur une autre plateforme ?
Verrouiller le support hardware du PhysX si la puce principale n'est pas une nV, c'est pas locker les jeux PhysX pour que ca tourne mal sur une autre plateforme ?
 

 
Le topic a disparu. Ils se sont rendu compte que c'était de la branlette ?
 

 
J'ai pas encore lu l'article, mais ça fait plaisir de voir un peu de terre à terre sur le net, je commençais à m'inquiéter ! Perso pour les perfs j'attends de voir s'ils vont lancer une version 512 ou 448 shaders (ou les deux). Une 512 perpétuellement paper-launchée devrait quand même être significativement au-dessus d'une 5870 stock. Et même pour la 448 je ne serais pas entièrement surpris d'un 15-20% de mieux en moyenne, plus en revanche j'y crois pas.
 
Avant d'aller sur le topic Fermi, je vous mets un ptit lien semiaccurate, long mais intéressant (et avec des infos, si on les croit, qui vont à l'encontre de ce qui a disparu chez bjorn3D, à savoir que Fermi n'a pas été du tout pensé pour DX11, mais était au départ un GPGPU sans capacités 3D !) : http://www.semiaccurate.com/2010/0 [...] acturable/
 
Toujours pas de tesselator selon charlie, donc. Au passage son explication sur le fait que vu que la tesselation utilise les shaders, un bench avec quasiment que de la tesselation va être très en faveur de Fermi, de façon totalement irréaliste, est plutôt logique. Pourra-t-on utiliser un 2ème Fermi en SLI dédié à PhysX et la tesselation ?
 
Bien sûr c'est ptêtre tout faux, il a une dent contre nvidia toussa, en tout cas c'est argumenté, contrairement à nombre de "news" et d'"articles" qui ont l'air directement écrits par nvidia.
 
Ah oui, j'oubliais : 280W

Pour rappel

Je ne comprend pas ta remarque sur le PhysX software (qui représente la majorité des jeux PhysX comme le souligne MEI).
En quoi ça tournerait mal sur une "autre" plateforme ? Ca va tourner de la même manière quelque soit le CPU et la CG. J'vois pas en quoi ça désavantagerait ATI.

PhysX en CPU est monothreadé et donc n'exploite pas les CPU multicores.
Si tu reprends l'exemple de Batman, les benchs favorisent forcément les configs à base de GPU Nvidia, les CPU étant sous exploité.

 
Il parle de la minorité de jeux où justement PhysX est principalement GPU, mais peut être fait sur le CPU (quand la config' ne plait pas à nvidia). Et comme physx CPU n'est pas optimisé, voire désoptimisé...

PhysX est propriété de nvidia, il a décidé de le développer sur ses GPU, ça me parait logique. Ils préférent passer du temps à l'optimiser sur leur GPU c'est normal, maintenant quelqu'un qui n'est pas content des perfs de sa config en physx, rien ne l'empêche de prendre une Nvidia.
La seule chose que je reproche à Nvidia sur ce coup c'est d'empêcher d'utiliser une carte NV en second pour physX quand la première est une ATI la c'est un protectionisme mal placé.

Le problème c'est que ca va plus loins que de l'optimisation, vu que normalement PhysX x86 est (était ?) multithread. C'est plutôt de la désoptimisation.

Y'a aucun jeu ou le PhysX CPU est limitant. Tu choisis entre avoir les effets ou pas, c'est tout.

Ce qui ne veut pas dire qu'un jeu PhysX software n'exploite pas le multicore (c'est juste que la gestion de la physique n'aura qu'une partie des ressources CPU, ce qui n'est pas spécialement mal. Si la gestion de la physique a besoin de + d'1 core pour tourner convenablement, tu mets délibérément de côté tous les CPU dualcore).
Mais ça n'explique pas le "ca tourne mal sur une autre plateforme". Sur quelle plateforme ça tournera mal ?

Batman, c'est du PhysX accéléré, ce n'était pas là-dessus que portait le désaccord.

Il a donc répondu à côté de la remarque de MEI ? Celui-ci affirmait qu'il y avait "beaucoup" de jeux PhysX sofware (plus que de jeu proposant du PhysX accéléré en tout cas). De ce fait, "NVIDIA n'a pas pour autant locké tout les jeux PhysX pour que ça tourne mal sur ATI" (MEI).

Ca c'est bon à savoir. Et cela montre qu'nVidia veut imposer son PhysX accéléré (qui ne marche que sur ses GPU) en augmentant artificiellement le gain apporté par l'accélération. Dans les faits, ce procédé malhonnête n'a pas énormément de succès...

Bah c'est toujours le cas, à la sauce Microsoft  
 
Pour ceux que ça intéresse de comprendre, je les invite à regarder ce qu'ils ont osé appeler "faciliter le développement multi-thread" concernant .Net, c'est assez affligeant tellement c'est... basique

2 exemples simples :
- la gros poids lourd EA avec NFS Shift, qui a part les pbs de pilotes fonctionne aussi bien sur ATI que sur NVIDIA malgré PhysX CPU. (avec les derniers patch et pilotes et sur RV870 plus que sur RV770)
- le petit indé. avec Trine qui fonctionne très bien partout en utilisant PhysX. (et là y'a pas de TWIMTBP de mémoire)
 
PhysX c'est pas le top du moteur physique, mais NVIDIA n'a pas essayé non plus de trop flingué ATI (et n'en a pas l'intérêt s'il veux "vendre" PhysX aux dev)

 
Ca rejoint néanmoins ce que je disais, depuis l'apparation des cartes ageia en 2006 les bons titres exploitant correctement PhysX se comptent sur les doigts de la main et ceci malgré le fait que nVidia n'aie cessé d'en faire la promo.
 
ps : pour UT3 celà ne se résume-t'il pas à quelques maps faisant office de démo ?

PhysX, sans lui les débats n'auraient pas la même intensité    
 
+ ou - HS : la GTX285 entre un dual E8400 et un i7 tous 2 @4GHz, les pefs varient beaucoup ?
 
(Dans le cas hypothétique où les GTX360-80 seraient convaincantes, cela peut il valoir le coup d'upgrader un cross de 4870 512, sachant que là je tourne sur un E8400@4 GHZ ou bien déjà l'écart entre e8400 et i7 sur une gtx285 est marqué ?)

La différence n'est pas énorme à fréquence égale, sauf cas spécifiques. Après ça évoluera probablement avec le temps, mais pour le moment les E8000 se démerdent encore pas mal du tout.
 
http://www.hardware.fr/articles/77 [...] l-amd.html

Ouai enfin y'a quand même de plus en plus de jeux ou rien que C2Q vs C2D donne un avantage.

 
PhysX n'est pas locké à un seul core.

 
PhysX est comme il est, il n'est pas mono-threadé par essence.
Batman est comme il est.
 

ouai enfin telle que je vois venir cette nlle carte et ces "features" compute ou autre nom marketing c'est que ca va roxer sur 3 benchs, roxer sur 3 jeux sponsorisés a la batman qui feront surtout en + une desoptimisation pour les autres chips....
et puis voila, faudra attendre la prochaine generation pour avoir qqchose de vraiment correct et surtout supporté par plus de jeux.
bon en attendant les fan boys vont se jeter la dessus pour faire les 3 benchs en disant que quand ca sera optimisé ca sera surpuissant (comme la fx5800 quoi )
 
fin bref du hardware sans du software (ou peu) c pas trés utile sauf pour se la péter en mode geek    
 
et pour ce qui est de la necessité en puissance de calcule , depuis que je fais plus de 3D ben a part le jeu, le vois pas trop l'utilité non plus.
 
vala juste mes 2 cents depuis que je lurke ce topic si technique    

En effet, au moins là on est plus ou moins d'accord...
 
Le problème est plus de proposer une lib CPU qui nécessite de faire tout le travail par les devs alors que pour la version GPU tout est parallélisé d'origine (vu que c'est naturellement parallèle), ça c'est ce qu'on appelle limiter l'efficacité des architectures tierces.
 
Les mécanismes prévus pour le multithreading sont de quel ordre au final? Car bon, si ça se résume à la "possibilité" de lancer des threads avec des locks à mettre soi-même...

Oui et non car en pratique les dev' veulent pouvoir contrôler finement la gestion des threads. Ils ont plusieurs "Job" a effectuer en parallèle, mais doivent allouer du CPU eux-même finement pour obtenir les meilleurs perfs globales. Ils ne peuvent ni laisser l'OS gérer les thread au petit bonheur la chance, ni les API prendre ce quelles veulent en ressources.
 
En mode GPU c'est différent, c'est le pilote 3D qui peut effectuer ce job directement.
 

Même si ce n'est qu'à ce niveau là, faut pas décodeur, n'importe quel développeur sait faire une application multi-threadée. Ça fait partie du B-A BA qu'on apprend au cours de la 2e année de DUT/BTS/Licence quoi...
 
Et puis de toutes façons, c'est pas comme ci y'avais pas OpenMP, boost::thread & autres pour nous simplifier encore plus le boulot...

http://www.octeam.fr/news/nvidia/n [...] 71475.html
 
Voila, correction d'une news qui se trouve etre une mise au point plûtot.
 
Donc rien de nouveau reellement, donc vous n'avez pas besoin de dire que vous le saviez deja de toute facon

 
Ok merci Gigathlon mais je joue pas en 800*600    
 
sur le topic HD58xx il me semble qu'il était passé un test avec des CPUs divers et variés (dual quad penryn 3 et 4 GHz i7 stock et o/c), dans des conditions de jeu, c'est plutôt cela qui m'intéresse, voir si comme pour la gtx295 il faut quasi obligatoirement un i7 o/c pour en profiter
 
Allez je m'attend à un ping-pong Gigathlon/MEI en réponse  

Perso je suis passé d'une E8400 à un Q9650, j'ai qu'une 8800 GTS 512, je joue en 1920, souvent AA0X vu les derniers titres, parfois quand meme en AA4X/8X sur des titres gentil (SF4/L4D2) et j'ai senti la différence, y'a moins de moment ou y'a des "lag" ponctuel.
 
C'est pas un revolution mais c'est plus agréable.
 
Apres clairement avec un CF/SLI le C2Q apporte encore plus.

Ok MEI merci beaucoup j'attendrais donc plus longtemps, et je changerai tout d'un coup CPU et GPU sauf si tu me vends ton Q9650 à prix cassé  

Si sur Batman AA en PhysX CPU, et pareil sur NFS Shift avant le patch 1.02 qui "corrige" la chose...

Faut pas confondre l'API et son utilisation.

 
au moins, pas grand monde doit se souvenir de ageia..

Te souviens-tu du site qui a publié ce test ?

 
Non, justement c'est une question détournée, si quelqu'un s'en souviens je veux bien qu'il me renvoi le lien  
 
@picturaw : ne sois pas si sarcastic, son lien n'est pas celui que je cherche mais il a quand même essayé    

 
Ils sont automatiques pour les rigid bodies.
Après tu as les mécanismes par compartiment mais j'ai pas joué.
Le comportement CPU/GPU est unifié.

C'est surtout que le 800x600 permet d'éliminer certains goulets d'étranglement non liés au CPU.
 
Au-delà de 800x600, tu ne pourras quoi qu'il arrive pas avoir mieux que ce résultat avec les mêmes réglages, et c'est là l'important. Ca peut changer l'ordre et même potentiellement foutre le plus mauvais CPU devant le meilleur, mais si déjà dans cette résolution le GPU ou tout autre élément limite, ça sera encore plus le cas. C'est probablement la raison pour laquelle les Phenom II ont parfois été jusqu'à montrer de meilleures perfs avec des réglages graphiques plus lourds, par exemple pour cause de meilleure latence du contrôleur PCI-E auquel est reliée la carte graphique ou une quelconque raison qui incrimine cette fois la plateforme et non plus le CPU lui-même.

Mais bon, au final même si on dit à tort qu'un CPU est plus rapide qu'un autre, c'est vrai quand même car ce qui compte ce n'est pas le CPU seul mais la plateforme qui l'entoure, donc it's same non ?

Bah visiblement au moins dans certains cas c'est faux puisque Deneb est franchement inférieur à Bloomfield mais peut le dépasser lorsqu'on sollicite le système
 
C'est un peu le même problème que les infos dévoilées sur le GF100 hier, juste au niveau de la plateforme entière. Si un CPU 10x plus performant est toujours bon à prendre, il ne faut pas pour autant que ces 10x se transforment en pratique en 0.9x à cause du chipset ou de la RAM.

 
Certes, mais je préfère quand même voir un comparo HD58xx/GTX285 en fonction de dual/quad penryn et i7 en condition de jeu, 1920 et détails élevés  

Avec un fps moyen et sur des scènes pas forcément les plus lourds, miam

Il me semble avoir vu trainer ça quelque part, et C2Q ou i7 ça faisait peu de différence.
 
Pour ce qui est de la comparaison 2/4 cores, un article était paru aussi, genre là http://www.hardware.fr/articles/77 [...] -jeux.html
 
En page 10, on peut voir que le seul jeu qui commence à profiter réellement de 4 cores est ArmA 2, mais ça part de tellement bas que... bref.

Y'a pas Lost Planet (et donc je pense de tout les jeux Capcom qui utilisent le MT Engine) qui est un jeu qui finalement n'est jouable qu'avec 4 cores (sinon on est trop près des 30fps quoi...), ou des jeux Source Engine qui on un support multithreadé très performant, mais si on est dans les 200fps de toutes façons.

Ouaip Lost Planet tire bien partie de 4 core
 
GTA IV aussi
Anno 1404 aussi