Reprise du message précédent :

 
Perso, je ne crois pas AMD sur parole, je constate juste que sur le forum il y a 1 topic pour activer PhysX sur un systeme avec radeon/GeForce... en bidouillant, et un autre où on peut activer le SLI sur chipset Intel... en bidouillant... J'en conclue donc qu'NV "bidouille" ses pilotes, quitte à désactiver des fonctions qui ne vont pas dans son sens commercial...

pour le coup du verrouillage de physx avec radeon/geforce c'est meme pas tres malin de leur part, parceque sans ce verrouillage, j'en connait qui acheterai une geforce en supplement de leur ati pour régler le probleme de physx, ca ferait des ventes pour nvidia, la ils sont pas tres futés.

AMD ne dit pas que PhysX est monothreadé :
"When they bought Ageia, they had a fairly respectable multi-core implementation of PhysX. If you look at it now it basically runs predominantly on one, or at most, two cores."

 
A qui le dis tu...

Tu vises à côté là.
 
Qu'ils exploitent mieux leurs CPU que les AMD, c'est une chose et personne ne vas leur reprocher.
 
Ce qui est reproché, c'est l'option de processor dispatch qui n'est disponible qu'avec un processeur Intel et qui en cas de processeur non Intel bascule automatiquement vers un codepath par défaut (sans même le SSE à l'époque des A64) alors qu'aux dernières nouvelles, il est assez simple de checker les jeux d'instructions supportés par les CPUs.

Ca veux rien dire. Ils ont peut-être simplement décidé de mieux géré les priorité des process/thread afin de ne pas changer tout le temps de core. (meilleur perfs sur les quand/dual core non monolithique et dans le cas de l'HT).  
 
En plus ce qui compte c'est la conso globale CPU pas le nombre de threads utilisé. Bref on ne peut pas conclure avec le nombre de threads utilisé en pratique.
 
Des benchs pratique personne n'a su en montrer d'un cas qui tournait plus vite ne mode CPU avec un vieux SDK qu'avec les derniers SDK.

PhysX permet encore de tirer partie de plusieurs core normalement.
 
Encore faut-il le vouloir, car a priori ce n'est pas le cas par défaut d'après ce que me disait Damien. Et forcément, si c'est NVIDIA qui code la partie PhysX d'un jeu, c'est pas forcément à leur avantage de multithreader l'implémentation

il faudrait qu'un site objectif et compétent s'interesse à ce probleme mais c'est du boulot je pense pour pas grand chose.

Sauf que les optis ne sont pas "Instruction Set Specific", mais "CPU Specific". Et là c'est pas dur a comprendre...  
P4 vs Core c'est pas le jeux d'instruction qui impactera le plus les perfs lors de l'optimisation. Mais bel et bien le debit de tel ou tel instruction.
Intel a 3 grande archis en // :
- Atom
- P6/Core
- Netburst
Et chacune ont des jeux d'instruction en commun, du x86 ou du x64 (une opti Core 2 x86 et x64 sera t elle identique  a cause des macroOps Fusion qui ne tourne pas en EM64T )
 
Etc...
 
Fait du code SSSE3 pour la beauté du geste en esperant qu'a coup sur il soit plus perfs c'est débile. Comme dit suffit de voir les gros projets opensource pour voir que parfois on utilise du MMX sur Core i7/Phenom mais du SSSE3 sur Core 2 et du SSE2 sur Athlon 64... (exemple au pif). Le compilo Intel c'est pas un humain qui passe des moins à vérifier, tester, comparer le code. Et donc l'opti générique ne peut JAMAIS être d'utiliser le plus récent jeu d'instruction.

Faut être un minimum réaliste, en pratique on alloue un budget fixe et limité de ressource CPU à la physique.
Donc multithreadé ou pas, sauf sur les cas type Core i7, on atteins toujours jusqu'à 25% des ressources globales dans le pire des cas ce qui reste déjà pas mal.

Tu te plantes, il y'a les deux dans le compilo Intel.
 
L'option /arch pour des optimisations génériques à un jeu d'instruction et l'option /Qx pour des optimisations spécifiques à un CPU.
 
Same player shoot again

Du réalisme c'est priorisé les thread entre eux afin que la physique ne prenne pas le pas sur le reste.
 
Limiter à un thread la physique alors que celle-ci va limiter le jeu à 10 fps lorsque les effets sont activés, c'est tout sauf réaliste vu que ce n'est pas utilisable.

Comme je viens de le dire dans le topic fermi, vous croyez pas qu'AMD aurait fait pareil si ils avaient racheté Aegia et Physx ?

Petit HS,
 
J'ai fais l'acquisition d'un 30'' ce weekend et j'ai un problème d'affichage que je n'ai pas réussi à règler.
 
Il y a une espèce de scintillement voir d'interférence qui apparait de façon aléatoire.
 
C'est visible que sur les fonds clairs, autant en 2d qu'en 3d ou lorsque j'utilise la roulette de la souris et quelle que soit la résolution utilisée.
 
J'ai vérifié le taux de rafraichissement et il est bien calé à 60Hz.
 
J'ai viré une 5870, booté sur le 2ième port pci-express, testé avec une 4890, sur un autre pc, testé sur les 3 prises dvi de l'écran, essayé le second cable dual-link fourni, les drivers 9.10/11/12, changé le câble d'alim de l'écran, viré mon ampli et mes enceintes et rien n'y fait.
 
Me reste l'option de tester à tout hasard avec une carte nVidia mais je n'en n'ai plus sous la main ou d'acheter un adaptateur display port-dvi-d qui coûte la peau des fesses...
 
J'ai cherché une solution sur le net sans réel succès, si ce n'est des soucis assez semblables au mien mais en multiscreen.
 
Bref si l'un de vous à une idée ou une soluce avant que je ne le renvoie, je suis preneur.
 
 

que se pose  le probleme sur la 5870 et sur la 4890 aussi c'est vraiment bizarre je pense plutot que ca vient de l'ecran, tu n'as pas un ordi portable a brancher dessus pour voir ?

Non, mais sur mon second pc avec un installation toute fraiche de V64 à jour, les symptômes sont identiques.
 

Tu utilises AMD GPU Clock ?

Possible, et donc, c'est bien pour autant ?
 
Tu crois que personne n'aurait rien dit ?

 
Non, je passe uniquement par le ccc.

http://en.expreview.com/2010/01/20 [...] /6484.html
 

 
 

TSMC says 40nm yield issues resolved
 

 
Chez moi, j'ai des symptômes similaires quand ma ram est OC.

cpu et cg @stock n'y change rien, avec mes 24'' aucun soucis particuliers.

Pas pire que la SAPPHIRE 4850x2
 

oué, sauf que la ça fait un peu 9800 gx2 mono pcb quoi    
 
a l'aube de la sortie des gt3xx  

 
T'a un cordon DVI dual link ?

Avec 1 Gigo  
 
Je viens bien de me payer une GTX280
On n'est pas obligé de suivre à la lettre l'actualité

non, mais bon, la ça fait quasi 2 gen d'écart

sortir un dual gpu d'une puce mdg (un peu bdg maintenant) datée de 2 gen, c'est fort quand même  

acheter des gt2xx ou hd4xxx c'est différent je trouve quand même (profiter des baisses de prix par exemple)

 
Oui, il y en avait même 2 fournis avec l'écran donc j'écarte la possibilité du câble défectueux.  

Eh bien moi je pense au contraire qu'elle doit bien se comporter, si elle sort on en reparlera (ou pas )

 
Le problème est pas d'arriver à mieux exploiter ses cpu que ceux des autres, mais de faire un fallback en i586 alors que tu pourrais travailler en i686+SSE et que le CPU expose ses extensions ouvertement. C'est légèrement problématique
 
Qu'un A64 avec SSE2/3 utilise le code d'un P3 alors que le P4D utilise du SSE3, y'a une légère dérive

 
Le bridage sur sa propre plateforme, sans doute.
Maintenant, le bridage multi-thread, c'est presque sur que non. AMD vend aussi des processeurs, et n'a donc pas intéret à brider sa solution vis à vis de ses processeurs.
 
nVidia est dans une position biaisée: ils vendent PhysX comme étant la justification absolue du CUDA/ComputeonGraphics. C'est donc dans l'intéret de leur biz de brider les performances sur "les autres solutions"...

Faut pas non plus oublier qu'en pratique les MMX/SSEx sont souvent exploités via de l'assembleur inline par les développeurs.
 

Le rageu

C'est la stricte vérité.
 
x264 tu peut le compiler sous ICL10 ça changera pas grand chose par ex.
 
De plus le compilo ne vectorisera jamais ton code tout seul. Donc la plupart du temps, de toutes façons les SSE ne sont même pas exploitable par le compilo. Déj que quasi aucun dev' n'utilise les directive OpenMP pour aider les compilos a parallélisé le code...

Ah oui ... fait voir ?

N'importe nawak
 
Le compilo peut vectoriser ton code tout seul : il suffit de mettre les bonnes options de compilation (optimisation en O3, no aliasing strict) et éventuellement indiquer l'indépendance des itérations dans les boucles à l'aide de directives de précompilation (#pragma ivdep pour icc). J'ai passé pas mal de temps à faire en sorte que mon code soit vectorisé par le compilo parce que je n'ai ni le temps ni les compétences pour le faire moi-même et les gains sont énormes (j'ai obtenu un facteur 3 dans le meileur des cas).
 
Bref, ta vision des choses me semble un peu étriquée. Un peu plus et je serais tenté de dire que tu ne sais pas de quoi tu parles

Un petit peu d'huile... oups de Physx sur le feu:
 
http://www.nokytech.net/physx_indi [...] 255-a.html

 
Y'a pas forcément de bridage.
Le multi-threading se fait sur des lots distincts d'objets en collision, séparés spatialement.
 
Sur les corps solides, si tu as un seul tas d'objet réveillés (physiquement actifs) dans une scène t'as qu'un seul worker thread, le nombre de threads faisant une résolution de collision ne scale qu'à cette condition (séparation spatiale).
 
Donc si le jeu est trop centré sur l'avatar du joueur (pas vraiment un monde avec une scène globalement active a plusieurs endroits), bah le threading est faible.

 
Tu codes avec quoi bjones ? un devkit NV ou tu passes par tes propres algos ?  

Sauf que sans vouloir trop m'avancer, pour le cas de Batman par exemple, je ne vois pas ce qui empecherait d'avoir un threading CPU fort pour les effets qui sont gérés en cas de GPU NV par le GPU (et avec un threading élevé a priori).