Reprise du message précédent :

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).

La fainéantise des dev' ?
 
C'est toujours pareil, y'a du y avoir une deadline précise et après on y touche plus sauf bug critique.
 
Par contre si dans Batman AA 2 c'est toujours pareil, là on pourra éventuellement crié au loup... et encore, ça serait classique de ne pas trop toucher à ce qui fonctionne...

 
Je sais pas trop, ce qui est envoyé vers le GPU c'est les fluides & les tissus, donc j'imagine que PhysX crée un thread (ou utilise le thread principal de contrôle) qui pousse et attends les résultats de simulations exécutés séquentiellement au niveau du GPU. (le thread stall a mon avis, donc il est pas visible dans l'utilisation CPU).
 

 
Pour PhysX le SDK public de base. Mais j'ai fait que l'implémentation des corps solides j'ai juste lorgné sur l'api des fluides & tissus. Donc vous inquiétez pas moi mon code il multi-thread très bien sans que j'ai rien à faire (puisque c'est au sein de PhysX que la répartition sur les worker thread se fait en fonction des îles de collisions).

Ca peut pas se voir avec le moniteur de ressources ça? Je me souviens à une époque lointaine d'un outil qui permettait de voir un autre chiffre que le gestionnaire des tâches concernant l'occupation CPU, ça permettait au passage de trouver des pilotes responsables de ralentissements monstre malgré une occupation CPU "visiblement faible"...
 
Enfin un thread qui glande c'est pas un CPU qui glande normalement, l'asynchronisme c'est pas pour les chiens

 
J'entends bien, mais le verrouillage aux 11fps montre quand même qu'il y'a quelque chose qui ne va pas du tout.
Un peu comme si le comportement GPGPU était émulé sur un seul thread de CPU au lieu d'être vraiment traduit en code x86 comme l'API est vendue comme pouvant le faire
 
Ce qui justifierai d'ailleurs que l'utilisation "software pure" du PhysX donne des résultats corrects, mais que l'utilisation "hardware/CUDA/GPGPU" donne systématiquement des résultats pourris si il n'y pas de dedicated hardware qui va bien.
En somme, l'API PhysX serait volontairement bridée si elle fait appel à du hardware "non présent" alors qu'elle a été vendue comme étant "universelle"...
 
Le fallback serait donc "bridé".

 
Je crois qu'on ne s'est pas compris.
 
Je te parle de multi-threader au niveau du CPU (en l'absence de GPU PhysX) les simulations faites au niveau du GPU (en présence de GPU PhysX).

 
Y'a un histoire de compartiments, alors je crois qu'il y a un coté explicité coté du dev, faudrait regarder les exemples du SDK.

C'est dingue ca!!          
 
Vous allez faire combien de post sur PhysX et Batman ??????????
en plus ici et dans le topic fermi...
Je ne sais pas si vous vous en rendez compte, mais c'est un debat sans fin, entre pro/utilisateur et anti.
 
Franchement, j'invite serieusement quelqu'un a créer les topics :
- Physx et ses defauts
- Le Lobbying des constructeurs auprès des editeurs de jeux.
 
 
A un moment faut vraiment arreter ces débats steriles qui saoulent tout le monde.

Si ca te saoule, déflag en même temps, c'est un Open Bar là.

Je me demande souvent combien ils sont à bosser sur les plans d'une puce comme fermi. J'imagine que c'est difficilement quantifiable (secret industriel oblige), mais j'aimerai vraiment savoir combien de personnes sont cachés derrière uniquement le design de la puce... genre combien de mecs(nanas) derrière les ROP, les bus, le VPU etc...
 
Un collègue de mon père m'avait montré les plans "simplifiés" du 68030 en 1995 et v'la déjà le bordel, alors pour une puce moderne  

Et dans un bar, on ne sert pas les alcooliques

 
Que fais-tu là alors BiereMan ?    
 
 
     
->

Je cours, tu vois bien ^^

Whou putain un smiley Kirby  !    
 
Trop fort  

Quelqu'un sait ou on peu trouver la roadmap d'ATi ?

 
Pareil  
 

 
Laquelle ?

2011 = nouvelle plateforme avec nouveaux CPU, chipsets et GPU.
 
C'est tout ce qu'on a comme roadmap.

 
Par contre c'est vrai que ça avait rien à faire dans le topic fermi

Mais les alcoolo si

 
En 2011 sortira la plateforme Scorpius, c'est-à-dire le successeur de la plateforme Leo . Elle sera composée ...

• d'un processeur Zambezi (Bulldozer)
• d'une carte graphique Northern Island
• d'un chipset de série 900 (990FX)

en fait j'avais vu un peu sur le topic bulldozer pour la partie CPU mais je voulais en savoir un peu plus sur les GPU.
Northern Island ça serait les 6xxx ?

 
Bah pour le moment on sait rien de ces fameuses "HD6000" donc je vais pas ouvrir un topic unik dessus ...  
D'après AMD, l'architecture serait différente . Alors que les HD5000 sont basées sur les HD4000, cette architecture-là devrait être bien meilleure ... m'enfin, c'est ce que disent tout le temps AMD et nVidia tous les ans à propos de leurs futures CG .

 
Oui, et ce sera la puce de mayrde d'AMD... Leur viet...heu !!! Fermi quoi.
 

 
Bah, étant donnée qu'on n'en sait strictement rien, je vois pas comment on pourrait commencer à perçevoir si les Northern Island seront bien ou pas .

Oh mais c'est pas un reproche

edit: j'adore comment certains sautent directement sur l'occasion et en profitent pour troller. A croire que tout post avec marqué dedans ATI ou Nvidia est trollable. Bien ouéj

 
Ce que je voulais dire c'est que pour le moment on ne peut rien dire (ou alors vraiment pas grand-chose, c'est de la spéculation poussée à l'extrême) sur la génération Northern Island . Il paraît qu'elle sera compatible avec DirectX 11.1 et composée de MIMD en lieu et place de SIMD ... mais les rumeurs ont trop de chances d'être erronnées à une distance temporelle si grande de l'annonce concrète des cartes par AMD, donc moi je dis qu'on n'en sait rien pour être sûr de ne pas se tromper .

Par contre je viens de test sur le SampleCloth du 2.8.1, en augmentant la résolution des tissus:
Sur un C2D:
 
Sur le test 1 (le drap Ageia):
 
Résolution d'origine:
- Hardware 60fps cappé - CPU à 30 47% de temps dont 20% de temps kernel
- Software 60fps cappé - CPU à 51% de temps CPU dont peu en temps kernel
 
Résolution du tissu (méchamment) doppée:
- Hardware 42fps - CPU à 26~30%, temps kernel faible à la moitié max
- Software ~6fps - CPU à 52%, temps kernel faible
 
=> En hardware, l'utilisation CPU ne représente pas le temps GPU, le thread principal  fait un stall et pis cé tout.
=> En software, la simulation du seul tissu de la scène ne prends qu'un core au max (le deuxième étant grignoté par le rendu, prévisible)
=> La 8800GT délivre 7x les perfs d'un core C2D à 2.4Ghz tout en libérant du temps CPU (ça change peut-être avec des patchs de tissus plus faible en résolution)
 
Sur le test 5 (les attachements):
Résolution d'origine:
- Hardware 60 fps cappé / 6~15%
- Software 60 fps cappé / 8~25%
 
Résolution doppée (et scène hacké la résolution du tissu change la simulation, extensibilité du tissu....):
- Hardware 60fps cappé / 30%, dont la moitié passé en temps kernel
- Software 25~27 fps / 53%
=> Il semblerait effectivement que le runtime ne répartisse pas les 3 tissus sur deux worker threads.
 
Donc là il faudrait utiliser les compartiments (avantage GPU: le gain de perfs se fait sans expliciter quelque chose, puisque le GPU va faire un traitement séquentiel des simulations).
 
Après faut voir si la scène a quelque chose qui gêne la répartition (et pourrait être un mauvais indicateur): le fait que les tissus de la scène que j'ai hacké soient crées en Two-way ou que les acteurs soient trop proches et se retrouvent réunis dans le même groupe de simulation.
edit: j'ai test ça a pas aidé.
 
J'ai pas test les fluides, c'est peut-être différent.
 
http://www.filehosting.fr/details/ [...] dc635bab82

 
Y'a des chances que non, je me souviens d'une déclaration de Dirk Meyer après les épisodes Phenom et R600 qui disait en gros:
 "désormais nous serons plus prudent niveau R&D et commercialisation de nouvelles architectures" , suffit de voir comment ils prennent leur temps avec fuzion    
Enfin c'est l'impression que j'ai aussi en voyant comment ils ont bonifié le R600 par petites touches, peut être que northern island est une nouvelle archi mais conçu sur la même base que la précédente, ou pas, c'est vrai qu'on en sait rien pour le moment  

 
Pas de Roadmap pour les:
- 5870 2go
- la SIX
- les 5890
 
???
 
Pourtant les 2 premieres ont été annoncées depuis plusieurs mois maintenant,
plus aucune news depuis, pas une info, ...

Ils attendent surement Nvidia pour faire la course de manière équitable

 
Bizarrement, mon petit doigt m'a dit qu'on aurait du nouveau mi-février/mi-mars... étonnant non ?
 

 
Oui, mais ATI a annoncé en grande pompe, a coup de video, de benchs, de communiqués de presse, etc
la gestion de plus de 3 ecrans, 6 pour etre plus précis avec Eyefinity.
 
A l'heure actuelle ce n'est pas possible (6 ecrans) (meme avec un cross de 5870?)
et il n'y a plus aucune nouvelle....
ni date de sortie...

Clair que les possesseurs de 6 écrans d'HFR doivent s'impatienter
Allez zou bon aprem et merci pour les infos Zack.

Fluides et tissus, c'est fondamentalement la même chose, peut-être plus lourd en fluide (car 3D et non 2D) mais ça reste le même type d'interactions.
 
Les soft bodies s'en rapprochent pas mal aussi.

En parlant d'EyeFinity, vous avez vu ça => http://www.presence-pc.com/actuali [...] ort-37937/ ?

Ca été dit dès le lancement des HD 5800, vous avez pas lu les tests ?

Moi non parce que je ne fais pas partie de la cible
Les prix des adaptateurs actifs sont hallucinants!

J'en ai vu à 20€ dans la liste des "validés EyeFinity", passifs qui plus est...
 
'fin bref c'est un peu le dawa cette histoire.

 
 
ah en effet, 460€ d'adaptateurs ca commence a chiffrer....
 
 
 
Pour revenir a ce que je disais, article du 11/09/2009:
Article de préssent d'Eyefinity
 
Ca fait quand meme plus de 5 mois....
 
Au passage un truc marrant de l'article:
 
"Les aficionados du terriblement "CPU-limité" Flight Simulator X devraient également être très intéressés par ces cartes, du moins si les pilotes sont au point puisque nous avons eut droit à l’inévitable plantage au cours de la présentation."
 
en réponse a un autre plantage plus récent lors d'une démo
Ca arrive à tout le monde